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1.  OBJECTIVES  AND  SUMMARY 
1.1.  Objectives 

The  objective  of  the  prefect  reported  here  has  been  to  provide  a  bridge  across  a  wide  gap  that  typically  exists 
between  research  and  the  application  of  its  results.  In  this  case,  the  research  concerns  the  MODEL  system  and  the 
area  of  software  development  Of  special  interest  are  the  software  development  of  applications  characterized  as 
complex,  time-critical,  medium  to  large  scale,  that  utilize  modern  computer  technology.  The  research  on  the 
MODEL  system  has  been  conducted  at  the  University  of  Pennsylvania  for  almost  a  decade  under  partial  sponsorship 
of  the  Office  of  Naval  Research.  The  pilot  project  objectives  are  to  verily,  measure  and  evaluate  the  impact  of  the 
innovations  in  MODEL  in  real  life  environment 

The  innovative  features  of  MODEL  will  be  discussed  in  detail  in  this  report  They  can  be  summarized  by  the 
following  three  main  points. 

1.  Automatic  support  for  the  entire  software  development  process.  The  MODEL  system  components 
perform  documentation,  checking  rod  code  generation,  spanning  die  development  of  requirements, 
modularization,  module  specification,  coding,  static  and  dynamic  debugging  and  performance 
evaluation. 

2.  Use  of  Equational  Language.  The  user  of  MODEL  defines  the  inherent  concepts  and  rales  of  the 
problem  through  equations.  The  automatic  system  (a)  aids  in  debugging  through  in-depth 
completeness  and  consistency  checks  and  (b)  transforms  the  statement  of  the  problem  into  highly 
efficient  programs. 

3.  Application  of  on-line,  concurrent! parallel  processing  technology  and  evaluation  of  performance  to 
guide  further  tuning  of  efficiency.  The  application  is  enhanced  through  use  of  operator/terminal 
interactions,  on-line  databases  and  interactions  between  concurrent  processes.  Performance  evaluation 
is  conducted  automatically,  reporting  to  the  user  program  computation  times. 

The  pilot  project  is  the  result  of  cooperation  among  three  Navy  agencies:  The  Office  of  Naval  Research  (ONR)  - 
sponsor  of  the  research,  the  Navy  Comptroller  (NAVCOMPT)  -  which  has  responsibility  for  Navy  financial 
systems,  and  the  Fleet  Accounting  and  Disbursing  Center,  Pacific  (FAADCPAQ  -  which  hosted  the  project 

/  The  Ship  Store  system  has  been  selected  as  a  highly  suitable  real-life  environment  to  investigate  the  effectiveness 
of  the  MODEL  system.  The  Ship  Store  system  is  used  for  financial  and  inventory  management  of  large  number  of 
stores  aboard  Navy  ships.  It  derives  its  complexity  and  size  from  the  large  number  of  diverse  inputs,  wide  reporting 
responsibilities,  and  particularly  the  need  for  a  man-machine  interface  to  balance,  reconcile  and  adjust  many  isolated 
but  connected  actions.  The  latter  require  complex  num-machine  interfaces,  on-line  databases  and  real-time 
communications  among  programs.  There  are  14  different  inputs  and  36  reports,  in  addition  to  large  on-line 
databases.  The  project  development  produced  automatically  38  programs  with  a  total  of  almost  50,000  lines  of  PL/1 
code.  4 - - - 


12.  Summary 

Through  implementation  of  the  Ship  Store  System,  the  project  verified  die  feasibility  of  using  MODEL  for  large 
scale  software  development  More  important  are  the  measurements  made  and  the  evaluation  of  the  effectiveness  of 
the  MODEL  methodology  and  automatic  systems.  Three  types  of  claims  are  made  for  MODEL. 

1)  Tripling  of  Software  Development  Productivity:  Verifying  improvements  in  productivity  required 
measurement  of  manpower  and  costs  of  the  development  from  the  initial  conception  of  an  application,  including 
development  of  requirements,  coding  and  testing,  to  the  point  where  the  developed  system  passed  a  strict  acceptance 
test  This  can  be  compared  with  similar  measurements  of  conventional  software  development  productivity  reported 
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in  technical  publications.  Widely  reported  statistics  and  models  of  conventional  software  development  have  been 
collected  by  Barry  W.  Boehm  in  "Software  Engineering  Economics",  Prentice  Hall,  1981.  There  are  many  factors 
Oat  effect  productivity.  The  evaluation  focused  on  the  number  of  statements  and  lines  of  code  in  a  high  level 
language  (PL/1)  produced  per  hour.  Boehm  reports  in  similar  ^plications  a  range  of  1-3  lines  per  man  hour.  This 
depends  greatly  on  the  complexity  of  the  application  and  proficiency  of  the  programmers.  The  project  reported  here 
is  considered  complex,  particularly  due  to  the  interactive  on-line  aspects  and  the  man-machine  interfaces  that  aid  the 
clerks  in  balancing,  reconciling  and  adjusting  transactions.  The  staff  employed  in  the  development  had  no  prior  data 
processing  experience.  Still  an  average  of  more  than  10  lines  of  PI/1  code  were  produced  per  man  hour. 

2)  Use  of  MODEL  by  non-programmers :  A  specification  of  a  program  in  MODEL  does  not  consist  of  a  computer 
solution  to  a  problem,  but  rather  of  a  mathematical  definition  of  die  problem  itself.  It  is  the  task  of  die  MODEL 
compiler  to  automatically  translate  the  specification  of  a  problem  into  highly  efficient  computer  programs  that  solve 
the  specified  problem.  Therefore  the  user  of  MODEL  is  not  directly  concerned  with  the  computer  solution  and  need 
not  have  computer  proficiency.  In  this  project,  FAADCPAC  assigned  to  the  Ship  Store  system  development  three 
persons  who  have  not  had  prior  exposure  to,  or  experience  in,  developing  computerized  business  date  processing 
systems.  Only  one  of  these  had  learned  previously  a  high  level  conventional  computer  programming  language  used 
on  a  personal  computer  (BASIC). 

3)  Detecting  high  percentage  of  errors  in  static  debugging:  The  MODEL  compiler  has  a  much  greater  capability 
of  detecting  errors  than  conventional  compilers.  Detecting  errors  through  the  compiler  and  their  correction  is  called 
static  debugging.  This  is  contrasted  with  dynamic  debugging  which  consists  of  detecting  errors  or  necessary 
changes  by  executing  the  program  with  real-life  data  and  making  appropriate  changes.  The  latter  is  several  fold 
more  costly  per  error  than  die  former.  Conventional  compilers  typically  detect  less  than  40%  of  the  logical  errors  in 
a  program.  The  MODEL  compiler  performs  many  additional  checks  and  the  collected  statistics  show  that 
approximately  80%  of  the  logical  errors  are  detected  by  die  compiler  and  corrected  in  static  debugging. 

The  report  is  organized  as  follows.  Section  2  gives  a  functional  overview  of  the  Ship  Store  system.  The  overall 
MODEL  methodology,  used  in  the  implementation,  is  described  in  Section  3.  Sections  4-6  deal  with  measurements 
and  presentation  of  implementation  statistics.  The  areas  of  special  interest  are:  training  of  users  -  Section  4, 
software  development  productivity  -  Section  S,  and  error  and  change  detection  and  correction  -  Section  6.  Section  7 
concludes  the  report. 

2.  THE  SHIP  STORE  SYSTEM 

The  Ship  Store  system  performs  typical  general  ledger  and  inventory  accounting  functions.  It  performs  these 
functions  centrally,  at  FAADCPAC,  for  over  200  stones  aboard  Navy  ships  in  the  Pacific.  Its  complexity  is  derived 
from  the  great  multiplicity  of  sources  and  destination  of  data  and  the  need  to  balance  and  reconcile  numerous  actions 
by  the  community  which  it  serves.  Especially  complex  is  the  analysis  and  man-machine  interface  to  help  clerks  find 
and  resolve  conflicts.  As  stated,  the  system  is  therefore  also  fairly  large  in  scope. 

The  Ship  Store  system  is  described  in  this  report  on  multiple  levels  of  details.  This  section  focuses  on  the  top 
level,  where  the  system  is  regarded  as  one  box  and  it  is  defined  functionally,  through  its  inputs  and  outputs.  Figure 
2-1  illustrates  also  the  overall  environment  surrounding  die  Ship  Store  system.  The  Ship  Store  system  is  represented 
as  a  central  box  in  the  figure,  showing  its  inputs  and  outputs,  their  sources  and  destinations. 
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2.1.  Functions  Of  The  Ship  Store  System 

Hie  Ship  Store  System  supports  FAADCPAC  managers  and  clerics  in  financial  management  and  in 

reporting  to  die  Naval  Research  Systems  Office  (NAVRESSO).  FAADCPAC  performs  the  following  functions  in 
conjunction  with  ship  stores. 

a.  Audit 

b.  Maintain  files,  effect  reconciliation  of 
documents  for  invoices  and  receipts 

and  balance  accounts  for  financial  statements 

c.  Affect  reconciliation  of  cash  reported  in  returns 

d.  Affect  payment  of  dealers'  bills 

e.  Consolidate  financial  statements 

The  Ship  Store  system  performs  automatically  items  b,c,  and  e  and  supports  the  other  items. 

As  shown  in  Figure  2-1,  input  to  the  Ship  Store  System  comes  from  two  classes  of  sources: 

Financial  Reporting  System  (FRS) 

-  including  purchase  invoices  (Registers  05  and  45),  transfer  invoices  (Register  1162  and  46), 
and  adjustment,  (Registers  33, 36  and  06). 

Ship  Stores  -  including  purchase  receipts  (*G’),  transfer  receipts  (’C),  deposit  ticket  (Register  14),  and 
SS153  financial  summaries. 

These  input  data  are  available  to  the  system  on  tapes  in  the  form  of  card  images.  The  input  programs  check  the 
validity  of  the  data  before  storing  them  in  the  database.  Clerks  use  the  system  to  resolve  the  more  difficult  errors  in 
the  input  data. 

Monthly  reconciliations  of  receipts  of  merchandise  and  invoices  are  performed.  Reports  based  on  reconciliation 
of  transactions  show  the  matching  status  of  every  invoice  or  receipt  in  die  system  and  the  summaries  of  different 
categories.  These  reports  provide  also  easy-to-reference  information  for  die  Ship  Store  clerks  in  researching  and 
resolving  the  more  complex  discrepencies. 

Tri-annually,  financial  statements  are  consolidated  to  produce  balance  sheet,  profit  and  loss  statements,  and 
consolidated  NAVCOMPT  Forms  145  and  146. 


22.  Background  Of  The  Ship  Store  System 

FAADCPAC  has  had  responsibility  for  financial  management  of  approximately  200  ship  stores  since  die  1960s. 
The  original  Ship  Store  System  has  been  batch  oriented  for  the  IBM  360  computer,  with  a  heavy  emphasis  on  tape 
and  card  files.  During  1980,  the  system  was  converted  to  the  UNIVAC  1100  computer  system  for  use  in  the 
NARDAC  network. 

Recently,  the  system,  has  been  audited  and  referred  to  as  "ineffective"  and  "incomplete".  Unsubstantiated  or 
duplicate  payments  to  vendors  have  been  a  significant  problem.  This  imposed  die  requirement  on  die  new  system  to 
reconcile  automatically  invoices  with  receipts,  and  provide  an  effective  interface  to  clerks  conducting  die  necessary 
investigations.  The  input  data  had  many  inconsistencies  which  required  incorporating  in  the  new  system  automatic 
balancing  of  accounts  and  correcting  of  erroneous  data. 


23,  Enhancements  Of  The  System 

Enhancements  in  die  new  system  implemented  by  nsing  MODEL  address  the  problems  outlined  in  the  previous 

section.  They  include  die  following: 

a.  Interactive  operation  by  darks  engaged  in  correcting 
inputs  and  balancing  or  reconciling  conflicting  data. 

b.  Terminal  display  -  update  -  retrieve  capability 

c.  Creation  of  database  files  that  can  be  updated  and 
perpetuated  on  a  current  basis  (rather  than  on 
periodical  basis) . 

d.  Concurrent  interactions  with  Ship  Store  clerks,  processing 
massive  input  and  updating  of  data 

The  benefits  resulting  from  these  enhancements  are: 

a.  Capability  to  edit  and  correct  inputs  and  balance 
and  reconcile  conflicts,  resulting  in  timely 
handling  of  unsubstantiated  or  duplicate  invoices. 

b.  Reduced  clerical  labor 

c.  Timely  updating  of  databases  (independently 
on  reporting  cycle) 

d.  Timely  reporting 

e.  Sase  of  maintenance. 


3.  MODEL  SOFTWARE  DEVELOPMENT  METHODOLOGY 

3.1.  Multi-Level,  Top-Down  Or  Bottom  Up  Approach  To  Development 

The  MODEL  system  can  support  both  the  top-down  and  bottom-up  approaches  to  application  development  It 
also  supports  additions,  changes  and  deletions.  This  capability  is  possible  because  of  the  nonprocedural  and 
concurrent  nature  of  MODEL.  All  changes  are  made  in  the  MODEL  language  specification  and  their  translation 
into  program  design  and  computer  operations  is  performed  automatically.  The  translation  is  invisible  to  the  users 
and  the  user  need  not  understand,  or  even  know  of,  the  complex  computer  technology  that  is  involved. 

Because  of  this  flexibility  it  is  not  necessary  to  provide  complete  detailed  requirements  for  the  application  prior  to 
beginning  individual  program  development  It  is  possible  for  instance  to  concentrate  first  on  the  more  complex 
program  modules,  rapidly  obtaining  prototypes,  and  use  die  remits  to  define  die  rest  of  the  application  Thus,  only  a 
broad  statement  of  objectives  was  available  prior  to  initiating  development  of  the  Ship  Store  System,  and  detailed 
requirements  evolved  later. 

The  MODEL  approach  distinguishes  between  global  and  local  aspects  of  the  implemented  system.  There  are 
separate  components  of  MODEL  for  these  two  purposes.  A  Configurator  component  accepts  as  input  a  data-flow 
like  diagram  of  the  system,  performs  consistency  checking  and  generates  command  language  code  for  setting  up 
communications  between  concurrently  operating  program  modules  and  initiating  respective  programs.  The 
Configurator  can  be  used  on  each  level  of  the  top-down  breakdown  of  the  application.  The  Compiler  accepts 


equadonal  specifications,  performs  the  sharking  and  generates  a  highly  efficient  program  in  PL/1.  This  is  illustrated 
in  die  following  for  a  top-down  approach.  A  third  component  of  MODEL,  the  Timer,  which  evaluates  the 
processing  times  between  inputs  or  output  is  oriented  to  real-time  applications  and  has  not  been  used  in  this  project 


3 2.  Multi-Level  Structure  Of  The  Ship  Store  System 
The  top-level  view  of  the  system  was  shown  in  Figure  2-1.  The  Ship  Store  system  is  shown  as  a  single  box  at  the 
center  of  the  diagram,  indicating  its  inputs  and  outputs. 

The  software  development  for  the  Ship  Store  System  was  then  divided  on  the  second  level  into  two  subsystems, 
for  Requisition  processing  and  Financial  processing.  The  subsystems  are  similar  to  one  another.  Both  of  them  have 
to  validate  input,  perform  reconciliation,  generate  reports,  and  allow  the  operator  to  modify  the  contents  of  their 
databases. 


Based  on  the  type  of  processing  required,  each  of  the  two  subsystems  is  further  divided  on  a  third  level  into  three 
areas: 

1.  Front  Office:  provide  interfaces  for  Ship  Store  clerics  to  perform  editing  and  modification  of 
transactions  stored  in  the  databases.  Clerks  requests  are  sent  to  the  back  office  to  be  carried  out  via 
intermodule  messages 

2.  Back  Office:  Respond  to  requests  from  the  front  office,  access  databases,  and  return  die  results  to  die 
front  office. 

3.  Batch  Process:  All  the  non-interactive  processing  including  input  handling,  balancing,  reconciliation 
and  report  generation. 


The  implementation  of  the  Ship  Store  System  is  thus  decomposed  in  a  top-  down  fashion  as  shown  in  Figure  3-1. 
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Figure  3-1  Multi-Level  Breakdown  Of  The  Shipstore  System 


The  whole  Ship  Store  System  is  decomposed  on  the  fourth  level  to  consist  of  38  MODEL  modules.  The 
complicated  module-to- module  and  module-to-file  interfaces,  especially  for  the  front  and  die  back  offices,  were 
established  by  using  the  MODEL  Configurator. 


33.  Program  Module  Development 

Most  of  die  development  time  involved  the  use  of  the  MODEL  compiler  for  checking  the  detailed  specification  of 
each  module  and  for  generating  the  respective  programs.  This  activity  was  carried  out  by  the  FAADCPAC  staff, 
working  independently,  but  consulting  with  the  on-site  CCCC  staff,  as  they  progressed. 

Essentially,  one  person  developed  the  front  and  back  offices  modules  for  both  the  Requisition  and  Financial 
subsystem.  This  part,  considered  the  most  complex  and  difficult,  was  developed  in  two  steps.  First  providing  a 
prototype  and  later  finalizing  the  modules.  The  other  two  persons  developed  the  Batch  subsystems  for  the 
Requisition  and  Financial  subsystems  respectively.  Each  person  typically  worked  on  one  module  at  a  time, 
composing  a  detailed  equadonal  specification,  debugging  it  statically,  and  then  testing  it  with  live  data  dynamically. 
Program  modules  were  synthesized  and  tested  as  they  were  completed,  to  create  progressively  larger  subsystems. 
This  was  done  by  use  of  the  Configurator. 

The  Configuration  of  the  batch  and  front  and  die  back  offices  is  shown  for  die  Requisition  and  Financial 
Subsystems  in  Figure  3-2  and  3-3  respectively.  It  shows  the  communications  between  modules  via  files.  It  was 
specified  in  the  MODEL  Configuration  Specification  Language  (CSL).  The  Configurator  translated  the  statements 
in  CSL  into  a  series  of  command  procedures  and  a  set  of  communication  mailboxes,  which  provided  the 
participating  modules  communication  facilities  and  ensured  the  synchronization  of  the  intermodule  message 
transfer.  The  Configurator  took  away  communication  interface  concerns  from  the  individual  module  developers, 
allowing  them  to  treat  communication  messages  as  regular  files. 


4.  TRAINING  OF  FAADCPAC  STAFF 

The  three  persons  assigned  by  FAADCPAC  to  the  Ship  Store  project  received  training  in  use  of  MODEL  over  the 
three  months  of  September  through  November  1984.  Previously  to  that  they  were  trained  by  FAADCPAC  in  use  of 
a  terminal  and  in  use  of  the  EMACS  editor  to  create  and  maintain  files.  They  did  not  have  prior  experience  in  either 
programming  or  business  data  processing  design.  One  person  learned  previously  the  use  of  the  Basic  programming 
language.  The  lack  of  previous  training  or  experience  by  the  assigned  FAADCPAC  staff  proved  beneficial  to  the 
objective  of  the  pilot  project  as  it  required  focusing  on  and  analysis  of  the  needs  of  training  in  MODEL. 

Formal  classes  in  the  syntax  and  semantics  of  MODEL,  including  a  refresher  on  arrays  and  equations,  were 
conducted  for  one  month  (September  1984).  This  was  followed  by  two  months  of  more  informal  training  on 
business  data  processing  concepts,  how  to  express  these  concepts  in  MODEL,  how  to  debug  specifications  and  how 
to  test  them  with  live  data.  The  two  months  period  also  included  learning  the  operation  and  design  of  the  original 
Ship  Store  system.  During  this  period  the  staff  also  identified  the  input  data  from  the  original  Ship  Store  system  that 
will  be  needed  later  for  testing  the  new  system. 

Several  of  the  more  difficult  training  topics  were  identified  in  the  training  as  follows: 

a)  Subscripting:  variables  in  MODEL  are  typically  envisaged  as  vectors,  matrices,  or  generally  multi-dimensional 
arrays.  The  elements  of  arrays  must  be  referenced  by  providing  with  each  variable  a  subscript  expression. 

b)  Debugging:  Inconsistencies  are  discovered  by  the  MODEL  compiler  in  dimensionality,  ranges  and  data  types 
of  referenced  arrays  and  by  circular  definitions. 

c)  Control  variables:  The  parameters  of  data  structures,  especially  the  ranges  of  dimensions  of  variables  can  be 
defined  dynamically,  to  depend  as  die  input  data. 

d)  Use  of  on-line  data:  This  requires  the  user  to  reference  data  structures  in  index-sequential  files. 
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The  above  concepts  must  be  taught  very  carefully, 

5.  SOFTWARE  DEVELOPMENT  PRODUCTIVITY 

As  described  in  the  previous  section  e  software  development  of  the  overall  system  was  partitioned  into 
Requisition  and  Financial  Subsystems,  e  a  further  divided  into  three  areas:  (a)  batch,  (b)  front  office  for  cleric 
interactions  and  (c)  back  offices  for  maintaining  and  updating  on-line  data.  These  areas  were  assigned  to  the  three 
FAADCPAC  members  of  the  project  for  independent  development. 

The  development  started  early  in  December  1984  after  the  above  high  level  breakdown  was  established. 
Development  area  (a)  progressed  substantially  from  die  beginning,  while  areas  (b)  and  (c)  required  approximately 
three  months  for  building  a  prototype  interactive  system  before  the  final  one  was  started.  The  input  programs  in 
area  (a)  were  emphasized  in  the  beginning  as  they  processed  input  of  data  that  was  necessary  to  test  the  rest  of  the 
system.  By  the  end  of  February  1985,  all  the  modules  for  input  of  data  were  completed  and  a  database  containing 
actual  Ship  Store  data  was  established. 

A  number  of  problems  were  discovered  in  the  MODEL  system  as  the  development  progressed.  The  problems 
were  corrected  on  a  continuous  basis  by  the  CCCC  personnel  in  Philadelphia.  The  facilities  of  the  MODEL  system 
were  enhanced  throughout  the  project  based  on  comments  from  the  FAADCPAC  staff. 

The  need  for  some  changes  to  the  initially  conceived  database  structures  became  apparent  during  the 
development,  requiring  modifications  to  the  previously  completed  modules.  The  nonprocedural  aspects  of  the 
MODEL  language  had  made  this  otherwise  complicated  job  easier. 

By  the  end  of  July  1985  all  modules  were  coded  and  mostly  tested  with  actual  data.  During  die  months  of  August 
and  September,  the  February  through  May  tri-annual  data  received  by  the  original  Ship  Store  system  was  loaded  to 
form  the  databases  for  a  thorough  test  of  the  new  Ship  Store  system.  Some  problems  due  to  the  huge  volume  of  data 
were  discovered  and  corrected.  Changes  were  also  made  for  more  flexibility  and  readability  of  the  reports. 

The  development  was  concluded  as  of  September  30, 1985.  A  total  of  38  programs  comprise  die  new  Ship  Store 
System.  Figure  5-1  shows  the  numbers  of  statements  and  lines  of  each  of  the  individual  programs  and  their  totals. 
Figure  5-2  shows  the  monthly  production  of  programs  over  the  ten  month  period.  (Dec.  1984  through  Sept.  1985) 

from  December  1984  through  September  1985,  a  total  of  4874  hours  have  been  spent  on  the  development 
Consisting  of  3816  hours  by  the  three  members  of  the  staff  of  FAADCPAC  assigned  to  the  project  and  1058  hours 
by  CCCC  staff  on-site  at  FAADCPAC  who  consulted  on  the  development  (Additional  526  hours  were  spent  by  the 
CCCC  staff  on  site  at  FAADCPAC  on  maintenance  of  the  MODEL  system).  Overall  productivity  in  terms  of 
MODEL  and  PL/1  statements  or  lines  per  man-hour  are  as  follows: 

MODEL  statements  par  hour  *•  4635/4874  ■  0.95 
MODEL  linas  par  hour  ■  21217/4874  ■  4.35 
PL/1  statements  par  hour  ■  30237/4874  ■  6.20 
PL/1  linas  par  hour  ■  48907/4874  ■  10.03 

As  discussed  in  Section  1,  this  has  been  compared  with  productivity  models  and  statistics  for  conventional 
methodology  (as  reported  by  Boehm).  This  supports  the  claim  of  tripling  the  productivity  by  use  of  MODEL  over 
conventional  high  level  programming  languages. 
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PROGRAM 

MODEL 

PL/1 

MODEL 

PL/1 

Hours 

HAMS 

Stmt 

Stmt 

Lines 

Lines 

%  of 

«  of 

Total 

total 

Requisition 

Input 

REG05 

174 

1110 

888 

1825 

RZG06 

147 

1079 

666 

1705 

REG1162 

149 

1074 

687 

1710 

RAG  3  3 

171 

1090 

864 

1796 

REG36 

167 

1086 

840 

1781 

REG45 

138 

1027 

711 

1655 

RE647 

134 

1019 

696 

1640 

REGGNC 

136 

870 

719 

1418 

TOTAL 

1216 

8355 

6071 

13530 

Requisition  Balancing 

GNCBAL 

67 

416 

341 

607 

REGSORT 

25 

242 

214 

389 

RBGBALP 

90 

694 

481 

976 

REGBALT 

83 

656 

427 

917 

TOTAL 

265 

2408 

1463 

2889 

Requisition  Reconciliation 

EXCTMTC4 

93 

556 

584 

1142 

PREP30F4 

52 

339 

229 

549 

JDAT30F4 

28 

570 

215 

932 

RMBR30F4 

28 

570 

214 

932 

PREPRCN 

24 

183 

73 

251 

REQRECON 

513 

3289 

1622 

4618 

TOTAL 

738 

5507 

2937 

8424 

TOTAL  Batch/Requiaition  Subsystem 

2219  16270  10471  24843  1272 

50.6%  26% 

Figure  5-1 (•)  Program  Development  Statistics  For  Batch/ 
Requisition  Subsystem. 


Productivity 
PL/1  lines/ 
per  hour 


19.5 


Program 


MODEL 

Stats 


PL/1 

8tats 


MODEL 

Linas 


PL/1 


«  of 
Total 


Hours  Productivity 
%  of  PL/1  linss 

Total  par  hour 


D.  Financial  Statement  Input 


NSS153 

167 

922 

645 

1718 

ANS0MM47 

116 

817 

409 

1187 

CPROJPROF 

155 

988 

686 

1537 

APROJB10 

120 

813 

401 

1167 

CASHSALE 

89 

572 

286 

821 

ANC SALES 

110 

630 

345 

914 

TOTAL 

757 

4742 

2772 

7344 

Financial 

Statez 

oent  Generation  and  Cash  Beconciliation 

STMT GEN 

249 

949 

1032 

1749 

CASHKECN 

64 

506 

263 

725 

TOTAL 

313 

1455 

1295 

2474 

Auxiliary  Modules 

BANKRCVR 

48 

460 

113 

654 

CLSEREQN 

44 

391 

106 

585 

CLSESTMT 

101 

850 

320 

1128 

CLSECASH 

48 

365 

143 

502 

TOTAL 

241 

2066 

682 

2869 

Total  for  Batch/Financial  Subsystem  and  Auxiliary  Program 

1311  8263  4749  12687  1742  7.3 

26%  35% 


Figure  5-1 (b)  Program  Development  Statistics  For  Batch/ 
Financial  and  Auxiliary  Programs 
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6.  Requisition  Editing  snd  Modificstion 


DISPATCH 

218 

776 

1158 

1368 

EDXTREQN 

181 

1085 

870 

1875 

MODREQN 

160 

874 

1411 

1946 

GOODNXTE 

12 

119 

30 

140 

TOTAL 

571 

2854 

3469 

5329 

H.  Financial  Statement  Editing  and  Modification 

DXSFTCHF 

135 

716 

633 

1199 

EDXTSTMT 

195 

1314 

822 

2393 

MODSTKT 

192 

1101 

1043 

2316 

GDNXTEF 

12 

119 

30 

140 

534 

3250 

2528 

6048 

Total  for  Front  and  Back  Office  subsystr 

ana 

1105 

6104 

5997 

11377 

1860 

6.1 

23% 

37% 

GRAND  TOTAL 

4635 

30237 

21217 

48907 

Figure  5-1  (c)  Program  Statistics  For  Front  snd  Back  Offices 
snd  Produced  Pl/1  Programs 


The  area  of  Front  and  Back  Offices  for  both  Requisition  and  Financial  Subsystems  was  die  most  difficult  one, 
involving  on-line  data  and  interactive  usage  screens.  The  productivity  in  this  area  was  therefore  die  lowest  6.1  PL/1 
lines  per  hour. 

The  area  of  Financial/batch  subsystem  was  next  in  difficulty,  as  it  included  financial  statement  generations  and 
various  calculations.  The  productivity  in  this  area  was  7.3  Pl/1  lines  per  hour. 

Finally  die  Requisition  subsystem  batch  ana,  had  a  number  of  similar  inputs,  which  accelerated  progress.  It  also 
however  included  the  complex  reconciliation  of  receipts  and  invoices.  The  productivity  in  this  area  was  19.5  PL/1 
lines  per  hour. 

6.  ERROR  DETECTION  AND  CORRECTION  AND  CHANGES  TO  IMPROVE 
PROGRAMS 

Error  detection  and  correction  is  probably  the  most  intellectually  demanding  and  costly  activity  in  software 
development  Typically,  it  accounts  for  close  to  half  of  the  total  cost  of  development  Errors  that  are  not  detected 
during  the  development  can  affect  reliability  and  confidence  in  the  application.  As  noted,  the  MODEL  compiler 
checks  at  considerable  depths  the  global  consistency  of  all  the  statements  and  locates  conflicts  as  precisely  as 
possible.  One  of  the  main  advantages  of  the  MODEL  approach  are  die  facilities  for  debugging.  They  make  a  major 


Overall 


l 


Interactive 

Operations 


contribution  to  die  high  productivity  obtainable  with  MODEL. 

One  of  die  objectives  of  the  project  was  to  categorize  the  errors  into  a  number  of  classes  and  analyze  the 
respective  difficulty  and  time  to  correct  each  class  of  errors. 

Errors  were  monitored  in  several  categories.  The  overall  development  of  a  module  can  be  viewed  as  consisting  of 
3  parts  -  initial  specification,  static  debugging  and  dynamic  debugging.  Note  that  subparts  of  each  part  can  be 
carried  out  incrementally,  and  the  user  can  alternate  from  one  part  to  another.  Error  breakdown  is  first  by  static 
checking  and  dynamic  rWHng  Static  checking  is  for  those  syntax  and  semantic  errors  detectable  by  the  MODEL 
Compiler.  Dynamic  checking  consists  of  detecting  incorrect  outcomes  when  the  compiled  programs  are  executed. 
Static  checking  is  by  far  less  costly  per  error  than  dynamic  checking.  This  section  summarizes  the  occurrences  of 
errors  in  these  major  categories  and  their  subcategories. 

Figure  6-1  summarizes  the  categories  of  errors  found  and  changes  made  during  the  development,  their  frequencies 
in  the  respective  categories,  the  average  time  required  to  make  a  correction  in  each  category  and  die  percentage  of 
overall  development  manpower  invested  in  correcting  errors  in  each  category.  This  information  is  important  to 
locating  areas  m  MODEL  where  additional  enhancements  would  contribute  the  most  Figure  6-1  also  gives  an 
insight  into  the  anatomy  of  software  development  with  MODEL. 
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Static  logic  errors  par  MODKL  stmt.  ■  0.30,  par  Fl/1  line  » 
Dynamic  errors  par  MODEL  stmt.  ■  0.17,  par  Fl/1  line  >0.0] 
Logic  errors  par  MODEL  stmt  ■  0.47,  par  FL/1  line  ■  0.044 

Figure  €-1  Error  and  Changes  Statistics 
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6.1.  Static  Checking 

The  error  ad  warning  messages  produced  by  the  MODEL  processor  for  every  compilation  were  saved  on  a  disk 
file  and  served  as  a  basis  for  the  statistics  in  Figure  6-1.  Following  are  the  explanations  of  the  subcategories  of  static 
checking  shown  in  Figure  6-1. 

Static  Checking  -  Syntax  Errors 

a)  Syntax  errors  occur  most  frequently  and  they  account  for  more  than  half  of  the  total  number  of  errors. 
Fortunately  this  type  of  error  is  the  most  easy  to  correct  Usually  they  are  simple  omissions  of  semicolons  or 
improperly  nested  IF-THEN-ELSE  phrases.  This,  type  of  error  will  not  be  further  considered  in  the  evaluation  of 
MODEL’S  error  detection  capability.  The  other  types  of  errors  involve  logical  inconsistencies  or  changes  required 
for  satisfactory  operation. 

Static  Checking  -  Logical  Errors  and  Changes 

b)  The  next  type  of  error  involves  the  use  of  control  variables.  Control  variables  are  used  in  MODEL  to  specify 
structural  and  organizational  attributes  of  data.  Improper  use  of  control  variables  occurred  more  often  at  the  earlier 
stages  of  the  project,  before  their  usage  has  become  familiar  to  the  development  staff. 

c)  The  nt  .  category  are  errors  due  to  wrong  specification  of  data  types.  Typically,  this  happened  because 
arithmetic  operators  were  used  on  character  strings.  During  the  period  of  development,  the  MODEL  compiler  was 
enhanced  to  better  explain  in  error  messages  the  causes  of  errors  in  this  category.  Therefore,  in  the  future,  the  time 
to  correct  these  errors  will  decrease. 

d)  ’’he  percentage  of  errors  caused  by  missing  subscripts  or  inconsistent  uses  of  subscripts  was  about  15%,  but 
thes  ’  urors  took  longer  to  correct 

e)  Errors  caused  by  ommission  of  variable  definitions  are  trivial  to  correct  because  an  error  message  pinpoints 
exactly  the  undefined  variable. 

62.  Dynamic  Checking 

Dynamic  checking  detected  not  only  logical  errors  but  also  deficiencies  in  the  operation  of  the  program  to  meet 
the  objectives  of  the  application.  Dynamic  emus  were  recorded  daily  manually  and  served  as  a  basis  for  the 
statistics  in  Figure  6-1.  Every  time  a  program  (or  a  set  of  programs  in  debugging  interactive  operations)  was 
executed  and  improperly  terminated,  the  error  was  analyzed  and  its  type  recorded.  Mare  than  50%  of  die  errors 
detected  by  dynamic  checking  occurred  while  debugging  the  interactive  operations.  Following  is  an  explanation  of 
the  subcategories  of  dynamic  checking  shown  in  Figure  6-1. 

a)  The  most  frequent  and  easy  to  correct  were  the  errors  or  inadequacies  in  specifying  the  data  formats  and  report 
layouts.  About  half  of  the  dynamic  errors  (45.1%)  were  of  this  type. 

b)  Data  conversion  errors  (14.4%)  usually  were  the  results  of  omitting  conditional  expressions  in  equations.  This 
resulted  in  undefined  variables  in  some  instances.  These  errors  were  relatively  hard  to  trace. 

c)  Errors  from  inaccurately  specified  calculations  resulted  mostly  from  wrong  initial  or  end  conditions  for 
calculating  totals  or  subtotals. 


d)  Errors  in  input  formats  were  the  easiest  to  detect  and  correct 
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e)  Errors  In  file  attributes  consisted  of  enoneengtaganization  of  files,  or  ranges  of  dimensions,  causing  references 
to  elements  outside  the  range. 

f)  Dynamic  errors  other  than  the  ones  mentioned  above  were  very  much  system-dependent  Since  the  VAX  VMS 
file  system  is  quite  flexible,  logical  file  name  assignments  are  sometimes  necessary  if  files  other  than  the  defaulted 
ones  are  to  be  used  in  testing.  File-not-found  or  inconsistent  attribute  errors  occurred  when  the  logical  name 
assignments  before  program  execution  were  omitted. 

63.  Highlights  Of  Error  Analysis 

The  statistics  cm  errors  and  changes  during  the  Ship  Store  application  software  development  are  shown  in  Figure 
6-1,  together  with  their  summaries.  The  overall  software  development  is  divided  into  three  parts-initial  composition 
of  specification  (22.6%  of  overall  manpower),  static  checking  (44.8%  of  overall  manpower,  divided  into  7.2%  for 
syntax  errors  and  37.6%  for  logical  errors)  and  dynamic  checking  (32 3%)  that  include  not  only  individual  module 
testing  but  also  acceptance  testing  of  die  entire  system. 

Figure  6-1  shows  also  a  further  breakdown  of  the  static/logical  and  dynamic  checking  into  error  categories. 
Subscripting  errors  in  static  checking  are  the  most  difficult  to  correct  The  MODEL  system  has  been  enhanced  by 
an  additional  report  and  more  precise  pointing  to  the  offending  statement  to  reduce  the  difficulty  in  correcting  this 
type  of  error. 

In  dynamic  checking,  errors  in  calculation  were  the  most  severe  to  correct  A  number  of  functions  have  been 
added  to  the  MODEL  language  to  be  used  for  summing,  averaging  and  searching,  over  vector  variables,  from  where  •'!'  “  *  - 
many  of  the  calculation  errors  originate. 

The  errors  in  the  subcategories  denoted  as  "others”  are  few  in  number  but  severe.  In  static  checking  they  include 
detection  of  circular  logic.  In  dynamic  checking  they  inclbde  errors  in  the  configuration. 

64%  of  the  logical  error  and  changes  were  detected  by  static  checking  and  36%  by  dynamic  checking.  The  latter 
includes  as  a  large  portion  changes  made  to  enhance  the  Ship  Store  application  based  on  rapidly  obtaining 
prototypes  of  programs  and  testing  them  with  data.  These  are  therefore  not  errors  in  logic  but  improvements. 

Finally  the  statistics  show  a  very  high  error  rate  per  MODEL  statement  (.4$,  namely  one  logical  error  or  change 
per  2  MODEL  statements.  This  amounts  to  one  error  or  change  per  23  FL/1  tines  of  produced  code).  This  is 
because  of  the  many  changes  made  as  a  user  progressively  increases  the  size  of  a  module  and  simultaneously 
determines  the  requirements  of  the  module  while  composing  a  module  specification.  It  also  reflects  the  effect  of  a 
learning  curve-with  the  staff  initially  making  more  errors,  which  receded  subsequently  to  a  constant  level  after  the 
third  months  of  the  project 

i 

7.  CONCLUSIONS 

The  objectives  of  the  pilot  project  were  achieved  as  follows: 

a)  Feasibility.  Use  of  MODEL  in  a  fairly  large  project  involving  both  diverse  data  and  complex  computation  was 
demonstrated. 

b)  Training :  We  demonstrated  that  personnel  without  prior  knowledge  of  data  processing  or  computer 
programming  can  be  effectively  trained  to  use  MODEL  in  software  development  of  large  applications. 

c)  Productivity.  Tripling  of  software  development  productivity  was  demonstrated.  This  agrees  with  much  of  the 
t 
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other  experience  in  use  of  MODEL,  prior  to  this  project,  and  concurrently  with  it,  by  users  of  MODEL  elsewhere. 

<0  Error  and  Change  Analysis:  Statistics  were  collected  on  categories  of  errors  and  changes,  giving  an  insight 
into  the  role  of  automatic  checking  of  consistency  and  completeness  by  the  MODEL  compiler. 

Much  has  been  learned  on  where  and  how  to  enhance  the  MODEL  system.  Of  greatest  importance  were  the 
lessons  learned  about  needed  thoroughness  and  completeness  of  training  and  additional  automatic  aids  in  debugging. 
Enhancements  were  made  to  the  MODEL  system  incorporating  what  was  learned  from  this  project. 

Another  important  lesson  learned  is  the  power  of  the  concurrent/  parallel  processing  techniques  built  in  MODEL. 
The  project  demonstrated  how  business  data  processing  can  be  greatly  simplified.  Use  of  concurrent  programs  that 
communicate  one  with  the  others  resulted  in  much  smaller  program  modules  than  if  stand  alone  programs  that 
communicate  only  through  data  fries  had  to  be  developed.  Also  the  concurrent  processing,  together  with  the 
nonprocedurality  of  MODEL  enabled  much  simplified  modularity  scheme  and  ease  in  making  changes. 

The  development  of  the  Ship  Store  system  utilized  the  VAX  family  of  Digital’s  computers  under  the  VMS 
operating  system.  Another  version  of  MODEL  operates  on  IBM  main  frames  under  VM/CMS  or  MVS  operating 
systems.  The  MODEL  compiler  operates  or.  relatively  small  computers  as  well,  on  Digital’s  Microvax  and  IBM’s 
PC-AT  370.  These  computers  can  also  operate  in  a  distributed  processing  network.  This  makes  it  feasible  also  to 
operate  the  Ship  Store  system  in  such  a  network.  For  example  a  small  computer  can  be  placed  in  each  Ship  Store  to 
make  corrections  to  the  data  at  die  source. 


